Method and system for providing access to content associated with an event

ABSTRACT

A content delivery system for delivering content received from one or more external sources to end users of the system via multiple communication paths. By way of non-limiting example, content such as a voice signal transmitted via a telephone network is received by a first server of the content delivery system. The first server alone or in concert with a second server converts and encodes the voice signal into a streaming format. In response to a request from an end user to receive the content via a selected communication path, the content delivery system converts and decodes the content, if necessary, to transmit the content via the selected communication path. The end user uses a computing device in communication the selected communication path to receive the content.

FIELD OF THE INVENTION

The invention relates to the field of content delivery and, inparticular, to a method and system for providing access to contentassociated with an event to end users via a plurality of communicationpaths.

BACKGROUND OF THE INVENTION

Increasingly, information and entertainment content is beingdisseminated via the communications infrastructure designed to be thebackbone of the Internet and wireless communications. These variouscommunications paths include the Plain Old Telephone Systems (“POTS”),the world wide web, and satellite and wireless networks, to name a few.Recently, content providers have turned to “web-casting” as a viablebroadcast option. Various events from live corporate earnings calls tolive sporting events have been broadcast using the Internet andstreaming video/audio players.

Generally speaking, web-casting (or Internet broadcasting) is thetransmission of live or pre-recorded audio or video to personalcomputers or other computing or display devices that are connected tothe Internet or other global communications network. Web-casting permitsa content provider to bring both video and audio, which is similar totelevision and radio but of lesser quality, directly to the computer ofone or more end users in formats commonly referred to as streaming videoand streaming audio. In addition to streaming media, web-cast events canbe accompanied by other multimedia components, such as, for example,slide shows, web-based content, interactive polling and questions, toname a few.

Web-cast events can be broadcast live or played back from storage on anarchived basis. To view the web-cast event the end user must have astreaming-media player, such as for example RealPlayer™ (provided byReal Networks™, Inc.) or Windows® Media Player provided by Microsoft®Corporation, loaded on their computing device. Furthermore, as set forthabove, web-casts that include other multimedia content such as slides,web content and other interactive components, will need at the veryleast a web browser, such as Netscape Navigator or Microsoft InternetExplorer. In general, the streamed video or audio is stored on acentralized location or source, such as a server, and pushed to an enduser's computer through the media player and web browser.

Web-casts are increasingly being employed to deliver various businessrelated information to end users. For example, corporate earnings calls,seminars, and distanced learning applications are being delivered viaweb-casts. The web-cast format is advantageous because a multimediapresentation that incorporates various interactive components can bestreamed to end users all over the globe. As such, end users can receivestreaming video or audio (akin to television or radio broadcasts) alongwith slide presentations, chat sessions, and web-based content, such asFlash® and Shockwave® presentations.

The widespread use of firewalls to protect corporate and home networks,however, has hampered the delivery of media rich content in the web-castformat. The common firewall prevents an end user inside the network fromaccessing non-HTTP content (or content transferred using the HypertextTransfer Protocol). Generally speaking, all information that iscommunicated to a firewall protected network passes through the firewalland is analyzed. If the content does not meet specified conditions, itis blocked from the network. For various reasons, corporate and homefirewalls block non-HTTP content, such as streaming media. Thus, mediarich web-casts cannot be streamed to many prospective end users.

Firewalls, however, are not the only obstacle to the proliferation ofweb-casting. To date, there are no sufficient means for deliveringweb-cast content to end users who for various reasons are away fromtheir personal computers. Thus, the inability of known systems todeliver web-cast and other streaming content to end users in multipleformats that can be accessed using a variety of communications andcomputing devices, such as for example, personal computers, wirelesstelephones, personal digital assistants (PDAs), and mobile computers,and the like, has hindered the growth of web-casting.

As such, there is a need for a system and method of delivering mediarich web-casts in multiple delivery formats that enables potential endusers to receive and participate in the web-cast behind firewalls, andfrom mobile locations.

SUMMARY OF THE INVENTION

The present invention overcomes shortcomings of the prior art. Thepresent invention provides for the delivery of content associated withan event, whether on a live or archived basis, to end users via avariety of communications paths. In addition, the present inventionenables end users to receive the content on a variety of communicationsdevices.

According to an exemplary embodiment of the present invention, a systemfor providing access to content associated with an event generallycomprises a server system that is capable of storing and transmittingthe content to the end users via multiple communications paths. Theserver system is communicatively connected to external content sources,which generally capture events and communicate the content associatedwith the events to the server system for processing, storing, andtransmission to end users. The server system also comprises a pluralityof interfaces that are communicatively connected to multiplecommunications paths. End users desiring to receive the content canchoose to receive all or a portion of the content on any one of thecommunications paths using a variety of communications devices. In thisway, end users access to the content is not limited by the particularcommunications device that an end user is using.

Generally speaking, the server system comprises a first converter forreceiving and encoding content transmitted from an external source. Aswill be described further, in one exemplary embodiment, the firstconverter captures voice data transmitted to the server system via POTS,converts the voice data into an audio file (e.g., a PCM or WAV file),and encodes the audio file into a streaming media file.

The server system also comprises a media storage and transmission servercommunicatively connected to the interfaces for providing access to theencoded content to end users. The interfaces may include connections tocommunications paths, including but not limited to the Internet, thePublic Switched Telephone Network (“PSTN”), analog and digital wirelessnetworks, and satellite networks.

Accordingly, a live video or audio feed can be received and formattedfor delivery through a plurality of interfaces and received by end usersusing a variety of communications devices. In this way, end users canparticipate in an event irrespective of the type of communication devicethe end user is using. For example, an end user who is traveling cancall a designated telephone number using a wireless phone and access theaudio component of an event. By way of further example, an end user canattend a virtual seminar broadcast over the Internet even when thenetwork is blocked by a firewall. In this instance, the non-streamingcomponent of an event (e.g., slides, chat windows, poll questions, etc.)can be viewed through the end user's web browser. The audio componentcould then be simultaneously accessed via telephone. As a furtherexample, in an alternative embodiment, the video feed could be formattedfor viewing on a handheld computing device, such as a Personal DigitalAssistant (“PDA”) or web-ready wireless phone. As can be seen, thepresent invention satisfies the need for a streaming-contentmulti-access delivery system.

By providing access via multiple communication paths, end users canaccess and participate in various events, including web-cast eventswhile at work, at home, or on the road. For example, by combining usageof the two or more of the interfaces, an end user can receivenon-streaming content, such as Flash® or Shockwave® presentations andslide images, on a personal or network computer on a Local Area Network(“LAN”), which is protected by a firewall, while receiving the audiocomponent of the web-cast via dial-up access. Thus, the variousembodiments of the present invention overcome the limitations of presentcontent delivery systems.

Other objects and features of the present invention will become apparentfrom the following detailed description, considered in conjunction withthe accompanying system schematics and flow diagrams. It is understood,however, that the drawings, which are not to scale, are designed solelyfor the purpose of illustration and not as a definition of the limits ofthe invention, for which reference should be made to the attendedclaims.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

In the drawing figures, which are not to scale, and which are merelyillustrative, and wherein like reference numerals depict like elementsthroughout the several views:

FIG. 1 is a schematic diagram of an overview of a preferred embodimentof the system architecture of a content delivery system in accordancewith the present invention;

FIG. 2 is a flow diagram of a process of configuring the contentdelivery system of FIG. 1 to capture content from external sources inaccordance with a preferred embodiment of the present invention;

FIG. 3 is a flow diagram of a process of capturing live voice data inaccordance with a preferred embodiment of the present invention;

FIG. 4 is a flow diagram of a process of capturing live video and/oraudio in accordance with a preferred embodiment of the presentinvention;

FIG. 5 is a data flow schematic of the delivery of content to an enduser via a telephone network in accordance with a preferred embodimentof the present invention;

FIG. 6 is a data flow schematic of the delivery of content to an enduser via the Internet in accordance with a preferred embodiment of thepresent invention; and

FIG. 7 is a flow diagram of a process of integrating non-streaming mediainto an event for delivery to end user in accordance with a preferredembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

There will now be shown and described in connection with the attacheddrawing figures several preferred embodiments of a system and method ofproviding access to live and archived events via a plurality ofcommunications paths 190 a, 190 b, and 190 c.

As used herein, the term “event(s)” generally refers to the broadcastvia a global communications network of video and/or audio content whichmay be combined with other multimedia content, such as, by way ofnon-limiting example, slide presentations, interactive chats, questionsor polls, and the like.

The term “communications paths” refers generally to any communicationnetwork through which end users may access content including but notlimited to a network using a data packet transfer protocol (such as theTransmission Control Protocol/Internet Protocol (“TCP/IP”), UserDatagram Protocol/Internet Protocol (“UDP/IP”)), a plain old telephonesystem (“POTS”), a cellular telephone system (such as the Advance MobilePhone Service (“AMPS”)), or a digital communication system (such as GSM,TDMA, or CDMA).

The term “interfaces” generally refers to any device for connecting theserver system to one or more of the communications paths, including butnot limited to modems, switches, etc.

Referring generally to FIGS. 1-7, according to an exemplary embodimentof the present invention, content associated with an event may bereceived (on a live basis) or stored (on an archived) on a contentdelivery system 100. As will be described in more detail below, accessinformation is provided to the end user to enable the end user to selectthe medium through which the end user desires to receive the content.Typically, the end user will perform an action, such as clicking a weblink or dialing the provided telephone access number, to indicate to thecontent delivery system 100 a selection to receive the content via oneof any number of communications paths 190 a, 190 b, 190 c. In responseto receipt of the end user's indication, the content delivery system 100transmits the content to a communications device 195 via the selectedcommunications path 190 a, 190 b, 190 c.

System Architecture

With reference to FIG. 1, there is shown an exemplary embodiment of acontent delivery system 100 in accordance with the present invention.

The content delivery system 100 generally comprises one or more serversprogrammed and equipped to receive content data from an external source50 (either on a live or archived basis), convert the content data into astreaming format, if necessary, store the data, and deliver the data toend users through various communication paths 190 a, 190 b, 190 c. In apreferred embodiment shown in FIG. 1, the content delivery system 100comprises a first server 110 for receiving and converting content data,a second server 120 for encoding the converted content data (or in someembodiments receiving content data directly from the external sources50), a third server 130 and an associated web-cast contentadministration system 135 for storing and delivering the content, afourth server 140 for decoding the content stored on the web-castcontent administration system 135, and a fifth server 150 for convertingthe content decoded by the fourth server so that the content can bedelivered to a voice communications device.

It will be understood that each of the servers 110, 120, 130, 140, and150, and the web-cast content administration system 135 are eachcommunicatively connected via a local or wide area network 105 (“LAN” or“WAN”). In turn, the first and second servers 110, 120 are incommunication with one or more external sources 50. Similarly, the thirdand fifth servers 130, 150 are in communication with variouscommunication paths 190 a, 190 b, 190 c through interfaces 180 a, 180 b,and 180 c, so as to deliver the content to end users.

In an exemplary embodiment of the content delivery system 100, as shownin FIG. 1, first server 110 is preferably equipped with a video/audiocontent capture device 112, which is communicatively connected toexternal sources 50.

Capture device or card 112 enables the first server 110 to receivetelephone, video, or audio data from an external source 50 and convertthe data into a digitized, compressed, and packetized format, ifnecessary. The first server 110 is preferably implemented in one or moreserver systems running an operating system (e.g. Windows NT/2000 or SunSolaris) and being programmed to interface with an Application ProgramInterface (“API”) exposed by the capture device 112 so as to permit thefirst server 110 to receive telephone, video, or audio content data on alive or archived basis. The content data, in the case of analog voicedata, is then converted into a format capable of being encoded by thesecond server 120. One or more capture cards 112 may be implemented inthe first server 110 as a matter of design choice to enable the firstserver 110 to receive multiple types of content data. By way ofnon-limiting example, capture devices 112 may be any telephony capturedevice, such as for example Dialogic's QuadSpan Key1 card, or anyvideo/audio capture device known in the art. The capture devices 112 maybe used in combination or installed in separate servers as a matter ofdesign choice. For instance, any number of capture devices 112 and firstservers 110 may be utilized to receive telephone, video, and/or audiocontent data from external sources 50 as are necessary to handle thebroadcasting loads of the content delivery system 100.

External source 50 is any device capable of transmitting telephone,video, or audio data to the content delivery system 100. Such data maybe received by the content delivery system 100 through a communicationsnetwork 75, such as, by way of non-limiting example, the Public SwitchedTelephone Network (PSTN), a wireless network, a satellite network, acable network, or transmission over the airwaves or any other suitablecommunications medium. By way of non-limiting example, external sources50 may include but are not limited to telephones, cellular or digitalwireless phones, or satellite communications devices, video cameras, andthe like. In the case of video and audio data other than voicecommunications, the external sources may transmit analog or digitaltelevision signals (e.g., NTSC, PAL, and HDTV signals) or radio signals(e.g., FM or AM band frequencies).

As will be described further below, when an event is scheduled, thefirst server 110 is pre-configured to receive the content data.Depending on the format of the raw content, i.e., standard telephonesignals, analog or digital television signals (NTSC, PAL, HDTV, etc.),or streaming video or audio content, the first server 110 functions toformat the raw content so that it can be encoded and stored on the thirdserver 130 and the associated web-cast content administration system135. In the case of standard telephone signals, the first server 110operates with programming to digitize, compress, and packetize thesignal. Generally speaking, the telephone signal is converted to a VOXor WAV format of packetized data. Because NTSC, PAL, and HDTV televisionsignals can be encoded by the second server 120 without conversion, thefirst server 110 either simply encodes the signal or passes the signaldirectly to the second server 120 on a pre-defined port setting. If theincoming video or audio feed is already in streaming format, whichrequires no conversion or encoding, the first server 110 can pass thestreaming content directly to the media server 130.

Referring again to FIG. 1, the second server 120 is preferably astandalone server system interconnected to both the first server 110 andthe third server 130 via the LAN/WAN 105. It will be understood,however, that the functionality of the second server 120 can beimplemented in the first server 110. Conversely, to handle large amountsof traffic any number of second servers 120 may be used to handletraffic on the content delivery system 100. The second server 120 isprogrammed to encode the converted video or audio content into astreaming media format. The second server 120 is preferably programmedwith encoding software capable of encoding digital data into streamingdata. By way of non-limiting example, such encoding software isavailable from Microsoft® and/or Real Networks®. One skilled in the artwill recognize that the process of encoding audio and video data intostreaming media formats may be performed in any number of ways now knownor hereafter developed. Once the content has been encoded into astreaming media format, it is passed to the third server 130 and theassociated web-cast content administration system 135 where it is storedand made available to end users.

The third server 130 is interconnected to the first server 110 andsecond server 120 via the LAN/WAN 105. The third server 130 is alsocommunicatively connected to end users via a global communicationsnetwork 200, such as the Internet. As shown in FIG. 1, the third server130 is also preferably connected to fourth and fifth servers 140 and150, respectively, for decoding and converting the content prior totransmission to end users when necessary for access through an voicecommunications medium such as cellular/satellite and public telephonenetworks.

The content delivery system 100 also comprises a fourth server 140, forconverting the streaming contents stored on the media server 130 into aformat acceptable to be transmitted over one of the communication paths190 a, 190 b, 190 c. For example, a streaming audio file or thestreaming audio component of a video stream generally must first beconverted into a non-streaming audio file, such as a .PCM or .WAV file,prior to being transmitted into an end user's telephone via the PSTN. Inan embodiment, described below, fourth server 140 operates inconjunction with a fifth server 150 for converting the decoded audiofile into a voice signal capable of being transmitted to a telephone. Ofcourse, it will be understood that the audio file can be converted intoeither analog or digital form. Similar to the first server 110, thefifth server 150 is equipped with a telephony interface device 155 suchas Dialogic's QuadSpan Key1.

As will be described further below, an end user can dial into thecontent delivery system 100 using a specified telephone access number tointerface with the telephony interface device 155 of fifth server 150.It should be noted that an advantage of the present invention is thatthrough the above-described system architecture an end user can selectthe medium through which he/she prefers to receive the data. Thus, theend user may also connect with the third server 130 throughcommunications path 190 a via a web browser. In addition, these multipleinterface connections enable the end user to receive both the audio andmultimedia components of an event simultaneously.

With further reference to FIG. 1, a web server 175 may be interconnectedto the LAN/WAN 105 as part of the content delivery system 100 or the webserver bay be operated as a stand-alone system. Generally speaking, asit relates to the present invention web server 175 functions to transmitaccess information for various events to end users.

Although not depicted in the figures, the servers described hereingenerally include such other art recognized components as are ordinarilyfound in server systems, including but not limited to RAM, ROM, clocks,hardware drivers, and the like. The servers are preferably configuredusing the Windows® NT/2000, UNIX or Sun Solaris operating systems,although one skilled in the art will recognize that the particularconfiguration of the servers is not critical to the present invention.

CONTENT CAPTURE

a. Configuring the Content Delivery System

With reference to FIG. 2, there is shown a flow diagram of an exemplaryprocess of configuring the content delivery system 100.

In a first step 202, a client accesses web-cast content administrationsoftware operating on the content delivery system 100. The web-castcontent administration software functions to receive data from theclient regarding a particular event and to configure the contentdelivery system according to the received event data. In step 204, asprompted by the web-cast content administration software, the clientconfigures the event parameters that include information such as, forexample, the time of the event, the look and feel of the event (ifgraphical), content type, etc. In step 206, the web-cast contentadministration software determines whether the event is a telephoneconference event, i.e., the content data is voice data as generated by atelephone. If the event is a telephone conference event, then theweb-cast content administration software generates a telephone accessnumber and associated PIN code to be used by the client in establishinga connection with the content delivery system 100, in step 208 a. Instep 208 b, the first server 110 is configured to receive the telephonesignal on the particular telephone access number.

Alternatively, if the event content will be received via a video oraudio feed, then in step 210 the first server 110 is configures toreceive the video signal via a communications network. In step 212, thesecond server 120 is configured to receive the captured content datafrom the first server 110. Similarly, the third server 130 is configuredto receive the encoded content data from the second server 120, in step214. One skilled in the art will recognize that the process ofconfiguring the servers can be performed in any number of ways as longas the servers are in communication and have adequate resources tohandle the incoming content data.

b. Live Telephone Feed Capture

With reference now to FIG. 3, there is shown a flow diagram of anexemplary process of capturing voice content from a telephone call.

Prior to hosting a live event, the content delivery system 100 isconfigured to receive the content data and make it available to endusers. Generally speaking, the capture device 112 of first server 110 isconfigured to receive the content from a specified external source 50.By way of example only, software operating on the content deliverysystem 100 assigns a unique identifier (or PIN) to a telephone accessnumber associated with a telephone line hard-wired to the capture device112. The capture device 112 preferably includes multiple channels orlines through which calls can be received.

In the case of a preferred embodiment, a telephony interface device(e.g., Dialogic's QuadSpan Key1). When an event is scheduled, one ormore lines are reserved for the event and the client (i.e., theperson(s) producing the content to be delivered to prospective endusers) is given an access number to call to interface with the system.The client (or host) uses the telephone access number and PIN with whichto dial into the first server 110 of the content delivery system 100 atthe time the conference call is scheduled to take place. In addition toconfiguring the capture device 112, the second server 120 and thirdservers 130 are configured to reserve resources for the incoming contentdata. One skilled in the art will recognize that the process ofscheduling the event and configuring the content delivery system 100 canbe performed in any number of ways as a matter of design choice.

In anticipation of the conference call, the capture device 112 of thefirst server 110 is set to “standby” mode to await a call made on thespecified telephone access line, in step 302. When the call is received,the content capture device 112 prompts the host to enter the PIN. If thecorrect PIN is entered, the data capture device 112 establishes aconnection, in step 304, and begins to receive the call data from theclient through the telephone network, in step 306. In step 308, as thecontent data is received, it is digitized (unless already in digitalform), compressed (unless already in compressed form), and packetized byprogramming on the capture device 112 installed the first server 110.The above step is performed in a manner known in the art. This functionsto packetized the voice data into IP packets that can be communicatedvia the Internet using TCP/IP protocols.

In step 310, the converted data is then passed to the second server 120,which functions to encode the data into a streaming data. Encodingapplications are presently available from both Microsoft and RealMediaand can be utilized to encode the converted file into streaming mediafiles. One skilled in the art will understand that while the presentinvention is described in connection with RealMedia and Windows MediaPlayer formats, the second server 120 can be programmed to encode theconverted voice transmission into any other now known or later developedstreaming media format. The use of a particular type of streaming formatis not critical to the present invention.

In step 312, once the data is encoded into a streaming media format(e.g., .asf or .rm), it is passed to the third server 130. In a liveevent, the data is continuously received, converted, encoded, passed tothe third server 130, and delivered to end users. During this process,however, the converted/encoded content data is recorded and stored on aweb-cast content administration system 135 so as to be accessible on anarchived basis. The web-cast content administration system 135 generallyincludes a database system 137 and associated storage (such as a harddrive, optical disk, or other data storage means) having a table 139stored thereon that manages various identifiers by which streamingcontent is identified. Generally speaking, content stored on theweb-cast content administration system 135 is preferably associated witha stream identifier (StreamId) that is stored in database table 139. TheStreamId is further associated with the stream file's filename andphysical location on the database 137, an end user PIN, and otherinformation pertinent to the stream file such as the stream type, bitrate, etc. As will be described below, the StreamId is used by thecontent delivery system 100 to locate, retrieve and transmit the contentdata to the end user.

One skilled in the art will understand that as a matter of design choiceany number and configurations of third servers 130 and associateddatabases may be used separately or in tandem to support the traffic andprocessing needs necessary at any given time. In a preferred embodiment,a round robin configuration of third servers 130 is utilized to supportend user traffic.

-   -   a. Live Video/Audio Feed Capture

In an alternate embodiment of the present invention, a live video feed(e.g., a television signal) or audio feed (e.g., a radio signal) maybetransmitted to the content delivery system 100. An exemplary process ofcapturing the live video/audio feed is shown in FIG. 4.

In general, live video feeds are de-mixed into their respective videoand audio components so as to be transmissible to end user in anydesired format via the several connected communications paths 190 a, 190b, 190 c to various user devices 195. Once the feed components arede-mixed, each can be encoded into a streaming media format, asdescribed above. The encoded video and/or audio streams are thencommunicated to the third server 130 and can be provided to end usersvia multiple communications paths.

In the case of a television or video signal, by way of example only, anend user can receive all of the components of the event, such as forexample the video component, the audio component, and any interactivenon-streaming component that may be included with the event. Forinstance, if the end user is behind a firewall, the end user might onlybe able to receive non-streaming components of the event on his/herpersonal or network computer. However, using the content delivery system100 of the present invention, the end user can access non-streamingcomponents on his/her computer while accessing the audio component ofthe event via the telephone dial-up access option described above.

With reference to FIG. 4, in step 402, a communication connection to thefirst server 110 is established. Generally speaking, resources on avideo/audio capture device 112 of the first server 110 are reserved forthe event and the first server 110 is configured to receive the signalthrough a specific input feed from external source 50. One skilled inthe art will recognize that the process of scheduling the event andconfiguring the content delivery system 100 can be performed in anynumber of known ways. In step 404, the transmission begins and, in step406, the video/audio signal is captured by the first server 110 andpassed to the second server 120, which encodes the video/audio signalinto a streaming media file, in step 408. In most instances, because thevideo/audio signal can be handled directly by the encoding programmingof the Second server without further conversion, there is no need todigitize or compress the video/audio signal. However, such digitizationand compression would be performed in a manner similar to the processdescribed above in connection with the voice signal.

In step 410, once the content is encoded into a streaming media format(e.g., .asf or .rm), it is passed to the third server 130. As describedabove, the streaming data is associated with a StreamId and otherpertinent information such as the location, filetype, stream type, bitrate, etc.

CONTENT DELIVERY

With reference again to FIG. 1, the content delivery system 100 providesaccess to the streaming content via multiple communications paths 190 a,190 b, 190 c. In connection with FIG. 5, there will now be described andshown an exemplary embodiment of delivery of audio/voice datatransmitted to an end user via telephone network 190 b.

-   -   a. Telephone Access

In step 500, information relating to how to access the event content isprovided to the end user. In a preferred embodiment, a telephone accessnumber is provided to the end user in a web site having basicinformation about the event. This web site may be served by web server175 or a web server operated by the client. In addition, by way ofexample, end users can be provided the access number and PIN via e-mail,written communication, or any other information dissemination method.

In step 505, the end user calls the telephone access number to establisha connection between the content delivery system 100 and the end user'scommunication device 195, in this example a cellular phone. Once aconnection is established, programming on the fifth server 150 promptsthe end user to enter his/her PIN code to gain access to the content. Instep 510, the end user's PIN is captured by the telephony interfacedevice 155, which communicates the PIN to the web-cast contentadministration system 135. In step 515, the web-cast contentadministration system 135 looks up and matches the PIN with the StreamIdof the requested content. Using the StreamId, the web-cast contentadministration system 135 looks up the location of the data (e.g., thebroadcast part) on the third server 130. In step 520, the web-castcontent administration system 135 locates the identified stream data onthe first server 130, which in turn patches the stream into decodingprogramming of the fourth server 140. In step 525, the fourth server 140decodes the stream into a non-streaming format (e.g., WAV or PCM). Instep 530, the decoded data is passed to the telephony interface device155 of the fifth server 150, which converts the decoded data into voicedata. In step 535, the voice data is output and communicated to thevoice communication device of the end user via a telephone network suchas PSTN or cellular networks, to name a few. The result is that the enduser can receive the stream using a telephone, even though the enduser's computer could not receive the stream because it is on a networkprotected by a firewall.

-   -   b. World Wide Web Access

Referring back to FIG. 1, the third server 130 is preferably connectedto the Internet, for example, or some other global communicationsnetwork, shown as communications path 190 a. In this respect, thecontent delivery 100 system also provides an access point to thestreaming content through the Internet. With further reference to FIG.6, a preferred embodiment of a process of accessing the streamingcontent through the Internet is shown and described below.

Upon completion of the scheduling and production phase of the event, auniform resource locator (URL) or link is preferably embedded in a webpage accessible to end-users. Any end users desiring to receive eventcan click on the URL. Preferably, a StreamId is embedded within the URL,as shown in exemplary form below:

-   -   <A href=“webserver.com/getstream.asp?streamid=12345”>

The illustrative URL shown above points to the web server 175 that willexecute the indicated “getstream.asp” program. One skilled in the artwill recognize that although “getstream” application has an ActiveServer Page (or ASP) extension, it is not necessary to use ASPtechnologies. Rather, any programming or scripting language ortechnology could be used to provide the desired functionality. It ispreferred, however, that the program run on the server side so as toalleviate any processing bottlenecks on the end user side.

Referring now to FIG. 6, in step 605, the “getstream” application makesa call to the database table 139 using the embedded stream identifier.In step 610, the stream identifier is looked up and matched with a URLprefix, a DNS location, and a stream filename. In step 615, a metafilecontaining the URL prefix, DNS location, and stream filename isdynamically generated and passed to the media player on the end usercomputer. An example of a metafile for use with Windows MediaTechnologies is shown below: <ASX>   <ENTRY>     <REFHREF=“mms://mediaserver.location.com/stream1.asf”>   </ENTRY> </ASX>

One skilled in the art will recognize, of course, that different mediatechnologies utilize different formats of metafiles and, therefore, thatthe term “metafile” is not limited to the ASX-type metafile shown above.In step 620, the end user's media player pulls the identified streamfile from the third server 130 identified in the metafile and plays thestream.

c. Non-Streaming Media Integration

In an alternate embodiment, shown in FIG. 1, the content delivery system100 may also include a non-streaming content server 160 that is used topush non-streaming content to the end user either in a pushed fashion oras requested by the end user. Because the non-streaming content serveruses the Hypertext Transfer Protocol (“HTTP”) and the content is ofnon-streaming format, the content can be received behind a firewall. Inthis way, an end user whose computer resides behind a firewall can dialin to receive the audio stream while watching a slide show on his/hercomputer. As will be discussed in further detail, several non-streamingcontent components can be incorporated into such an event.

Turning now to FIG. 7, an exemplary embodiment of the operation of asoftware program processed by the content server 160 to allow the clientto incorporate various media content into an event while it is runninglive is shown. The exemplary embodiment is described herein inconnection with the incorporation of slide images that are pushed duringthe live event to a computing device of the end user. It should beunderstood, however, that any type of media content or other interactivefeature could be incorporated into the event in this manner.

Referring again to FIG. 7, the client accesses a live eventadministration functionality of the web-cast content administrationsoftware (“WCCAS”) to design a mini-event to include in the live event,in step 702. The WCCAS then generates an HTML reference file, in step704. The HTML reference contains various properties of the content thatis to be pushed to the multimedia player. For instance, the HTMLreference includes, but is not limited to, a name identifier, a typeidentifier, and a location identifier. Below is an exemplary HTMLreference:

-   -   http://webserver.co.com/process.asp?iProcess=2&contentloc=“&sDatawindow&”&name=“&request.form(“url”)

The “iProcess” parameter instructs the “process” program how to handlethe incoming event. The “contentloc” parameter sets the particular datawindow to send the event. And, the “name” parameter instructs theprogram as to the URL that points to the event content. As describedabove, during event preparation, the client creates the event scriptwhich is published to create an HTML file for each piece of content. TheHTML reference is a URL that points to the URL associated with the HTMLfile created for the pushed content.

The WCCAS then passes the HTML reference to the live feed coming in tothe second server 120, in step 706. The HTML reference file is thenencoded into the stream as an event, in step 708. In this way, the HTMLreference file becomes a permanent event in the streaming file and theassociated content will be automatically delivered if the stream file isplayed from an archived database. This encoding process alsosynchronizes the delivery of the content to a particular time stamp inthe streaming media file. For example, if a series of slides are pushedto the end user at different intervals of the stream, this push order issaved along with the archived stream file. Thus, the slides aresynchronized to the stream. These event times are recorded and can bemodified using the development tool to change an archived stream. Theclient can later reorder slides.

In step 710, the encoded stream is then passed to the third server 130.Preferably, the HTML reference generated by the WCCAS is targeted forthe hidden frame of the player on the end user's system. Of course, oneskilled in the art will recognize that the target frame need not behidden so long as the functionality described below can be called fromthe target frame. As shown above, embedded within the HTML reference isa URL calling a “process” function and various properties. When theembedded properties are received by the ASP script, the ASP script usesthe embedded properties to retrieve the content or image from theappropriate location on the web-cast content administration system 135and push the content to the end user's player in the appropriatelocation.

Next, the third server 130 delivers the stream and HTML reference to theplayer on the end user system, in step 712. The targeted frame capturesand processes the HTML reference properties, in step 714.

In the exemplary embodiment, the name identifier identifies the name andlocation of the content. In an alternate example, the “process.asp”program accesses (or “hits”) the web-cast content administrationdatabase 137 to return the slide image named “slide1” to the player inappropriate player window, in step 716, although this is not necessary.The type identifier identifies the type of content that is to be pushed,e.g., a poll or a slide, etc. In the above example, the type identifierindicates that the content to be pushed is a JPEG file. The locationidentifier identifies the particular frame, window, or layer in theweb-cast player that the content is to be delivered. In the aboveexample, the location identifier “2” is associated with an embeddedslide window.

The content is then returned to the player in the appropriate window, instep 720.

By way of further example only, an HTML web page or flash presentationcould be pushed to a browser window. By way of further example, ananswer to a question communicated by an end user could be pushed as anHTML document to a CSS layer that is moved to the front of the web-castplayer by the “process.asp” function.

In this way, the client can encode any event into the web-cast inreal-time during a live event. Because the target frame functions tointerpret the embedded properties in the HTML reference—rather thansimply sending the content to a frame, the content is seamlesslyincorporated into the player.

An advantage of use of this system is that an end user, whose computerresides on a network having a firewall, can receive the event contentvia one or more communication paths 190 a, 190 b, 190 c. For instance,the integrated non-streaming components of an event, as described above,could be receive through the firewall on an end user's personalcomputer, while the streaming components (e.g., streaming video oraudio) could be simultaneously received via a second communications path190 a, 190 b, 190 c. By way of example, a video feed can be de-mixedinto its audio and visual components. Further, a non-streaming componentcan be integrated. The end user could be provided a telephone accessnumber and PIN to access the audio component via a telephone whilewatching the slides on his/her computer. In addition, the video or audiocomponents could be accessed by the end user on a portable device 195,such as a personal digital assistant or other handheld device, viawireless data transmission on a wireless communications path 190 c.

While the invention has been described in connection with preferredembodiments, it will be understood that modifications thereof within theprinciples outlined above will be evident to those skilled in the artand thus, the invention is not limited to the preferred embodiments butis intended to encompass such modifications.

1. A method of making content associated with an event accessible to acommunications device of an end user via a plurality of communicationpaths, the content comprising at least a streaming component, the methodcomprising: (a) receiving the content into a server system incommunication with the plurality of communication paths; (b) providinginformation to the end user on how to access the content; (c) receivingan indication from the end user to receive the content via a selectedone of the plurality of communication paths, the indicationcorresponding to an action taken by the end user in requesting thecontent; (d) determining a format for the streaming component of thecontent requested by the end user appropriate for transmission to theend user via the selected communication path; (e) converting thestreaming component into the determined format, if the content is aformat different from the determined format; and (f) transmitting atleast the streaming component of the content to the communicationsdevice of the end user via the selected communication paths.
 2. Themethod of claim 1, wherein step (b) comprises embedding a link in a webpage pointing to the content and the action taken by the end user isclicking on the link.
 3. The method of claim 2, wherein the selected oneof the communication paths is the world wide web.
 4. The method of claim2, wherein the communications device of the end user is a computer. 5.The method of claim 2, wherein the communications device of the end useris a cellular phone.
 6. The method of claim 2, wherein thecommunications device of the end user is a hand held computing device.7. The method of claim 6, wherein the hand held computing device is apersonal digital assistant.
 8. The method of claim 1, wherein step (b)comprises providing a telephone access number and a code to the enduser, the code being associated with the streaming component of thecontent, and wherein step (c) comprises calling the telephone accessnumber and inputting the code.
 9. The method of claim 8, wherein step(e) comprises: decoding the streaming component into an audio file andconverting the audio file into voice data capable of being received by atelephone.
 10. The method of claim 9, wherein the telephone is acellular phone.
 11. The method of claim 9, wherein the telephone is awireless device.
 12. The method of claim 9, wherein the streamingcomponent is decoded into a non-streaming format.
 13. The method ofclaim 13, wherein the selected one of the communication paths is apublicly switched telephone network.
 14. The method of claim 1, whereinthe selected one of the communication paths is a cellular network. 15.The method of claim 1, wherein the selected one of the communicationpaths is a digital communications network.
 16. The method of claim 1,wherein the content further comprises a non-streaming component.
 17. Themethod of claim 16, wherein a script of commands embedded in the contentis associated with the component and step (b) comprises providing theend user with a link to access the non-streaming component and step (f)comprises transmitting the non-streaming component of the content to theend user according to the script of commands.
 18. The method of claim17, wherein the nonstreaming component comprises a series of images andthe script of commands defines a sequence according to which the imagesare transmitted, and step (f) further comprises: pinging thecommunications device of the end user to determine which of the imagesof the series of images was last transmitted to the communicationsdevice; and transmitting a next one of the images to the communicationsdevice according to the sequence.
 19. The method of claim 19, whereinthe images are presentation slides.
 20. The method of claim 17, whereinthe non-streaming component comprises a series of web pages and thescript of commands defines a sequence in which the web pages aretransmitted and step (f) further comprises: pinging the communicationsdevice of the end user to determine which of the web pages was lasttransmitted to the communications device; and transmitting a next one ofthe web pages to the communications device according to the sequence.21. The method of claim 1, further comprising receiving the content froman external source communicatively connected to the server system. 22.The method of claim 21, wherein the content is received in anon-streaming format and the method further comprises converting thecontent into a streaming format.
 23. The method of claim 22, wherein thestep of converting the content into a streaming format comprises:digitizing the content; compressing the digitized content; packetizingthe digitized and compressed content; and encoding the content into thestreaming format
 24. A system for providing access to content associatedwith an event to an end user via a plurality of communication paths, thesystem comprising: a server system for receiving the content from anexternal source, the server system comprising: a first server incommunication with the external source, the first server for receivingthe content and converting at least a portion of the content into afirst format; a second server for encoding the content; a third serverfor storing the content, the third server capable of transmitting thecontent via a first one of the communication paths through a firstinterface; a fourth server for decoding the content into an intermediateformat; and a fifth server for converting the content into a formattransmissible via a second one of the communication paths through asecond interface; wherein, in response to a request from the end user toreceive at least a portion of the content on the second interface, theserver system converts the portion of the content into the format, suchthat the converted portion of the content is transmissible via thesecond interface.
 25. The system of claim 24, wherein the firstinterface is connected to the world wide web and the second interface isconnected to a telephone network and wherein said first format is astreaming media format and said second format a voice signal.
 26. Thesystem of claim 24, wherein said intermediate format is a digitizedaudio file.